Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/001463_daemon _Mon Jun 28 01:30:10 1993.msg

Internet Message Format | 1994-01-24 | 4KB

Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA10181; Mon, 28 Jun 93 01:30:12 MET DST
Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA10177; Mon, 28 Jun 93 01:30:10 MET DST
Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA14948; Mon, 28 Jun 1993 01:53:27 +0200
Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
    id AA18954; Sun, 27 Jun 1993 19:53:25 -0400
Received: by rock.west.ora.com (5.65c/Spike-2.1)
    id AA03818; Sun, 27 Jun 1993 16:53:24 -0700
Message-Id: <[e-mail]>
From: Terry Allen <[e-mail]>
Date: Sun, 27 Jun 1993 16:53:23 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: [e-mail]
Subject: One PRE, and entities

Dear Dave:
Sorry not to respond sooner to your post of Monday last, pointing
out HTML+'s style attribute for PRE.  This is okay, but maybe
not the most economical approach.

I think there are two issues:  1) the spec's definition of
leading white space and line breaks as significant within PRE,
and 2) font changes within PRE.  Presently, 1 seems to work just
fine (at least in xmosaic and lynx, the two browsers I'm using
for trials), so it should not be necessary to institute a <BR>
tag to get line breaks within PRE.  Outside PRE one shouldn't
need them (counterexamples welcome).

Presently, however, PRE is defined as having typewriter type
as its default font, and I think that's wrong.   I'd rather have
to invoke that font (by <CODE>) explicitly, the default font
remaining the same as the main text.  That way I don't need
an <R> tag, which has also been suggested, and when I
have an address to display, I can type:
<PRE>
       Name
       Address
       Telephone.
</PRE>
and get three indented lines in the main text font.
I think that if the definition of PRE is changed in this way
the style attribute might not be needed.

On another topic you mentioned, charsets, wide fonts, and
outline fonts, what I gleaned from the recent discussion of
Unicode on comp.text.sgml is that it shouldn't wreck the
SGML mechanism.  For what is not supported by Unicode, should
we choose to go that rather quirky route, the SGML external
entity mechanism is the obvious method, as you point out.
We already have character entities in the HTML DTD; all that's
needed is to establish how to reference external entity sets not
actually included in the HTML+ DTD.  SGML rather envisions that
the entity files are available locally at run time; for WWW it
might be better to be able to indicate the entity files are on
the same machine the document is being fetched from.

And if we can reference external entities, we can do something
requested this week in my office:  use entities to represent
URLs.  Than means 1) URLs themselves may be extracted from the
main document and collated in a referenced navigational document,
and 2) common link types may be generated automatically:  for
any "Next" link, my &next; entity can refer to a script that
looks through a list of filenames, chooses the one after the
current file, and returns that as the URL for the target of
the link.

I'l like to suggest that references to external entities go
in the HEAD of the document.

Regards,
.


--
Terry Allen  ([e-mail])
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472